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Abstract 

An  Ada  9X  binding  to  the  proposed  object  database  standard,  ODMG-93,  is  presented. 
The  major  decisions  necessary  for  such  an  effort  are  described.  The  approach  allows  Ada 
programmers  to  use  a  single  language  to  access  object-oriented  database  functionality  regardless 
of  vendor.  Briefly  mentioned  is  our  successful  feasibility  test  using  an  Ada  83  compiler  with 
Ada  package  implementations  for  ObjectStore  and  ITASCA. 


1  Introduction 

This  paper  identifies  the  major  decisions  involved  in  creating  an  Ada  language  binding  for  the 
Object  Definition  Language  (ODL),  Object  Manipulation  Language  (OML),  and  Object  Query 
Language  (OQL)  proposed  in  the  ODMG-93  object  database  standard  [1:11-81].  As  with  the  other 
ODMG-93  language  bindings,  the  primary  goal  is  for  Ada  programmers  to  feel  they  are  using  a 
single  language  to  access  the  underlying  ODBMS  functionality. 

Similar  to  the  steps  in  creating  a  C-|— k  ODBMS  application  [1:86],  Figure  1  illustrates  the 
process  for  creating  an  application  in  Ada.  Object  declarations  in  the  form  of  package  specifications 
are  scanned  by  the  ODL  preprocessor,  which  translates  them  to  the  corresponding  schema  and 
database  files  in  addition  to  generating  any  required  auxiliary  packages.  An  Ada  OML  preprocessor 
is  not  required,  as  all  ODMG-93  constructs  manipulating  objects  may  be  defined  in  Ada  9X  with 
respect  to  a  root  ancestor  object  (Section  2).  Likewise,  an  Ada  OQL  preprocessor  is  not  required 
due  to  the  loosely  coupled  approach  for  implementing  queries  (Section  5).  The  resulting  source 
code  along  with  the  Ada  binding  is  compiled  and  then  linked  with  the  ODBMS  to  produce  an 
application. 

The  object  database  standard  integrates  well  with  Ada’s  packaging  approach  to  encapsulation 
and  information  hiding;  a  single  package  specification  independent  of  any  vendor’s  ODBMS  can 
be  used  to  provide  access  to  a  category  of  ODMG-93  constructs  using  the  syntax  set  forth  in  the 
standard.  The  corresponding  vendor-specific  package  bodies  can  implement  them  for  a  particular 
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Figure  1:  Creating  an  Executable  Ada  ODBMS  Application 
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system.  Ada’s  use  clauses  can  then  be  incorporated  to  make  the  constructs  appear  as  a  natural 
extension  to  the  language. 

Ada  83  is  the  language  commonly  referred  to  simply  as  “Ada,”  but  because  of  its  inability  to 
model  inheritance  it  cannot  be  used  with  the  standard  unless  a  convention  for  modeling  inheritance 
is  decided  upon.  Ada  9X,  the  object-oriented  version  of  Ada  83  currently  in  the  final  standardization 
process,  is  the  only  Ada  language  that  can  be  used  “as  is”  with  ODMG-93.  As  the  new  compilers 
will  soon  become  available  this  paper  concentrates  on  Ada  9X,  and  unless  explicitly  stated,  “Ada” 
will  reference  Ada  9X  instead  of  Ada  83. 

In  the  rest  of  this  paper  we  discuss  the  binding  approach  we  used  for  Ada  9X  utilizing  the  new 
inheritance  capabilities  of  the  language.  We  then  discuss  and  provide  examples  of  the  binding  for 
the  ODL,  OML,  and  OQL  in  ODMG-93.  Finally,  we  discuss  our  feasibility  test  using  Ada  83  and 
package  bodies  for  ObjectStore  and  ITASCA.  The  complete  binding  is  presented  in  Appendix  A. 

2  Language  Binding  Approach 

The  most  important  decision  for  the  Ada  ODMG  language  binding  is  the  overall  approach  to  object 
definition  and  manipulation,  as  this  decision  then  dictates  the  definition  of  all  remaining  ODL  and 
OML  constructs.  The  approach  chosen  for  Ada  is  termed  inheritance-based. 

This  approach  is  similar  to  the  “Ref-based”  approach  for  the  ODMG-93  C-b-b  binding  [1:84-85], 
which  refers  to  instances  of  persistence-capable  database  classes  using  the  template  class  Ref,  or  a 
reference  to  the  instance.  In  the  Ref-based  approach,  the  ODL  preprocessor  automatically  defines 
the  class  Ref  <X>  for  every  database  class  X  specified  by  the  user.  The  template  class  allows  objects 
to  be  accessed  in  a  manner  similar  to  C-b-b  pointer  types,  with  additional  facilities  for  guaranteeing 
integrity  in  pointers  to  persistent  objects  [1:99].  Furthermore,  the  class  Pobject  is  defined  as  a 
superclass  of  all  persistence-capable  objects,  allowing  the  parameters  to  ODMG  contracts  to  be 
defined  as  Ref<Pobject>  [1:108].  The  ability  of  Ada  9X  to  model  inheritance  allows  it  to  use  an 
approach  quite  similar  to  the  C-b-b  Ref-based  approach. 

Figure  2  illustrates  one  possible  declaration  for  package  Persistent,  from  which  all  persistence- 
capable  database  classes  may  be  derived.  A  new  persistent  object  is  created  and  placed  in  a  database 
“near”  (implementation  dependent)  a  given  clustering  object,  if  provided.  Like  the  C-b-b  template 
class  Ref  <>,  additional  mechanisms  for  guaranteeing  integrity  can  be  incorporated  in  this  package. 

A  persistence-capable  class  X  may  now  be  defined  using  a  modified  version  of  ROMAN-9X 
notation  [2:390],  one  of  several  techniques  for  modeling  inheritance  in  Ada  9X,  as  shown  in  Figure 
3.  ROMAN-9X  defines  the  object  record  using  keyword  private,  preventing  the  user  from  accessing 
these  attributes  directly  (as  shown  in  Figure  2).  Here,  the  record  definition  is  moved  to  the  public 
section  of  the  package,  eliminating  the  need  to  define  accessor  routines  for  each  attribute.  New 
attributes  may  be  added  within  the  record,  and  methods  may  be  introduced  as  procedures  and 
functions.  Figure  4  shows  the  definition  of  an  example  ODMG-93  operation  using  the  inheritence- 
based  approach. 

3  Ada  ODL 

Having  selected  the  approach  for  designing  the  interface,  the  Ada  language  binding  for  the  remaining 
ODMG-93  constructs  follows  naturally.  The  database  schema  is  defined  as  a  set  of  packages,  each 
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package  Persistent  is 


type  Object  is  private; 

type  Reference  is  access  all  Object'Class; 

function  Create (A_Database  :  in  Database . Object ; 

Clustering  ;  in  Reference  :=  null) 

return  Object; 

procedure  Delete (An_0bject  :  in  Object); 
procedure  Mark_Modif ied(An_Object  :  in  out  Object); 

private 

String_Max  :  constant  :=  300; 
type  Object  is 
record 

Name  :  String (1 . .String_Max) ; 

Modified  ;  Boolean; 

end  record; 

end  Persistent; 


Figure  2:  Superclass  For  Ada  Persistence-capable  Classes 

with  Persistent; 
package  X  is 

type  Object  is  new  Persistent .Object  with 
record 

Attribute_One  :  Attribute_One_Type ; 
Attribute_Two  :  Attribute_Two_Type ; 
end  record; 

type  Reference  is  access  all  Object’Class; 


end  X; 


Figure  3:  Example  Ada  Persistence-capable  Class 
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procedure  Name_Object (An_0bject  :  in  out  Persistent .Object ; 

Name  :  in  String) ; 


Figure  4:  Example  Inheritence-based  Ada  Operation 


with  Person,  Student,  Set; 
package  Faculty  is 

package  Student_Set  is  new  Set (Student .Object) ; 

type  Object  is  new  Person. Object  with 
record 

Advisees  :  Student _Set. Object  inverse  Student .Advisor ; 
end  record; 

end  Faculty; 


Figure  5:  Example  Relationship  Definition 

representing  a  unique  object  class.  As  shown  in  Figure  3,  attributes  are  defined  for  an  object  class 
in  Ada  by  extending  the  attributes  of  the  record  defined  in  the  superclass  package. 

Relationships  between  objects  may  be  defined  using  the  collection  generic  Set  (discussed  in 
Section  4.2)  and  keyword  inverse,  specifying  inverse  traversal  paths.  Because  the  keyword  inverse 
is  not  part  of  standard  Ada,  it  will  need  to  be  removed  by  the  preprocessor  before  compilation.  An 
Ada  object  class  may  then  declare  a  relationship  using  the  syntax  shown  in  Figure  5. 

Consistent  with  the  definition  of  any  Ada  abstract  data  type,  operations  are  defined  by  the 
procedures  and  functions  in  the  package  representing  an  object  class. 

4  Ada  OML 

This  section  discusses  binding  ODMG-93’s  OML  to  Ada.  Every  effort  must  be  aimed  toward  adher¬ 
ence  to  the  principle  that  manipulating  persistent  objects  is  syntactically  equivalent  to  manipulating 
transient  objects. 

4.1  Object  Creation,  Deletion,  and  Modification 

The  object  creation  and  deletion  operations  are  best  defined  in  package  Persistent  and  refined 
in  the  persistent-capable  packages.  Consistent  with  the  other  ODMG-93  language  bindings,  Ada 
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with  Persistent,  Database,  Person; 
package  Faculty  is 

function 

Create (Database  :  in  Database. Object; 

Clustering  :  in  Persistent .Ref erence 

=  null; 

Name  :  in  Name_String 

=  (others  =>  ’  ’); 

SSAN  :  in  Integer 

=  0; 

Birthday  :  in  Birthday_String 

=  (others  =>  ’  ’ ) ; 

Dept  :  in  Department_Type 

=  N0_DEPT; 

Salary  :  in  Float 

return  Object  is 

Instance  :  Object; 
begin 

=  0.0) 

Instance  :=  Person. Create (Database,  Clustering,  Name, 

SSAN,  Birthday); 

Instance .Dept  :=  Dept; 

Instance .Salary  :=  Salary; 
return  Instance; 
end  Create; 

Figure  6:  Example  Object  Creation 


programmers  must  have  the  ability  to  manipulate  both  persistent  and  transient  instances  of  objects. 
Overloading  the  Create  and  Delete  operations  can  accomplish  this. 

To  create  persistent  instances,  the  user  must  produce  a  Create  function  with  a  parameter  of  type 
Database  .Object;  to  incorporate  clustering,  an  additional  parameter  of  type  Persistent  .Ref  erence 
may  be  included.  The  same  applies  to  the  Delete  procedure.  Attribute  initial  values  are  assigned 
as  default  values  in  the  function  stub.  Figure  6  illustrates  this  concept.  Similar  to  creating  an 
instance  of  an  inherited  class  in  C++,  the  ancestor  instances  are  created  first.  When  the  instance 
of  root  class  Persistent  is  created,  the  persistent  object  is  placed  in  the  corresponding  database 
near  the  given  clustering  object,  if  applicable. 

If  the  user  also  wishes  to  manipulate  transient  instances,  he  or  she  is  responsible  for  defining  one 
or  more  additional  Create  and  Delete  routines  without  including  the  database  or  clustering  pa¬ 
rameters.  These  routines  will  simply  be  standard  Ada  functions  and  procedures  based  on  the  user’s 
needs.  Consistent  with  the  C++  binding,  all  other  operations  for  manipulating  persistent  objects 
can  also  be  used  to  manipulate  transient  objects,  with  the  exception  of  queries  and  transactions. 

An  object  can  be  modified  by  manipulating  the  attribute  and  relationship  properties  defining 
its  state. 
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with  Persistent,  Collection; 
package  Relationships  is 

package  Persistent_Set  is  new  Set (Persistent . Object) ; 

pro c edur e  Re lat e _One _To_Many_Cr eat e 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object ; 

Related_Set  :  in  Persistent_Set .Object) ; 

procedure  Relate_One_To_One_Create 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object ; 

Related_Object  :  in  out  Persistent .Object) ; 


Figure  7:  Example  Relationship  Creation  Operations 


4.1.1  Attributes 

Attributes  may  be  manipulated  by  the  programmer  directly  using  Ada’s  standard  notation  for 
manipulating  record  fields.  If  the  record  definition  is  moved  to  the  private  section  of  the  package, 
accessor  procedures  and  functions  for  each  attribute  will  be  required.  However,  these  operations 
may  be  added  by  the  ODL  preprocessor  rather  than  the  programmer.  No  accessor  procedures 
or  functions  should  be  allowed  on  relationship  attributes,  as  these  are  best  manipulated  with  the 
operations  in  package  Relationship. 

4.1.2  Relationships 

Package  Relationship  can  be  used  to  define  the  ODMG-93  relationship  operations.  Figure  7 
illustrates  the  creation  operations  for  one-to-one  and  one-to-many  relationships.  One-to-one  rela¬ 
tionships  must  be  implemented  as  pointers  to  other  objects,  rather  than  a  copy  of  the  object,  to 
preserve  data  integrity.  Because  collections  are  defined  as  pointers  (in  Section  4.2),  an  additional 
level  of  dereferencing  is  not  required  for  one-to-many  and  many-to-many  relationships. 

4.2  Collections 

Similar  to  the  templates  used  to  implement  collections  in  the  C-|— I-  binding,  Ada  generic  packages 
should  be  used  to  implement  collections.  In  the  Ada  binding.  Collection  simply  provides  a  way  to 
encapsulate  the  properties  and  operations  common  to  all  collection  subclasses;  it  is  not  an  instan¬ 
tiate  abstract  data  type.  The  proposed  designs  of  package  Collection  and  each  of  its  subclasses 
appear  in  Appendix  A.  Each  subclass  defines  its  own  object  type  as  new  Collection. Object  to 
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package  Faculty_List  is  new  List(Faculty.Object) ; 
Chairman , 

Vice_Chairman  :  Faculty. Object; 
Math_Faculty_List  :  Faculty_List. Object  := 
Faculty_List . Create ; 

Faculty_List . Insert_First_Element (Chairman, 
Math_Faculty_List) ; 

Faculty_List . Insert_Element_Af ter (Vice_Chairmaui ,  1 
Math_Faculty_List) ; 


Figure  8;  Example  List  Instantiation  and  Manipulation 

allow  visibility  to  the  collection  properties  and  operations.  The  array  collection  is  renamed  Array. 
Type  to  avoid  illegal  use  of  Ada  keyword  array.  Figure  8  illustrates  an  example  instantiation  and 
manipulation  of  a  List  object  in  Ada. 

The  type  representation  for  collections  is  chosen  here  to  be  a  subtype  of  System. Address.  The 
underlying  ODBMS  is  therefore  responsible  for  converting  its  collection  type  representation,  thus 
allowing  collections  to  be  manipulated  as  pointers  in  the  Ada  binding.  Iterators  are  defined  in  a 
similar  manner. 

4.3  Transactions 

Package  Transaction  can  be  defined  to  encapsulate  all  transaction  operations.  Because  a  transac¬ 
tion  can  be  represented  in  several  ways  in  an  ODBMS,  type  Transaction .  Object  is  best  defined  as 
a  subtype  of  System.  Address.  The  underlying  implementation  will  then  be  responsible  for  convert¬ 
ing  its  particular  transaction  representation  type  to  the  address  type.  Function  Begin — returning 
a  Transaction. Object — along  with  procedures  Commit.Txn,  Abort.Txn,  Checkpoint,  and  Abort. 
To.TopT.evel — requiring  transaction  parameters — may  then  be  defined.  The  ODMG-93  abort  op¬ 
eration  should  be  renamed  Abort _Txn  since  the  former  is  an  Ada  keyword.  For  consistency,  the 
commit  operation  be  renamed  Commit  _Txn. 

4.4  Database  Operations 

Package  Database  can  be  defined  similar  to  the  transaction  package.  Type  Database  .Object  then 
represents  the  address  of  a  database  file.  Function  Open  returns  the  address  of  the  file  referred  to 
by  the  string  parameter,  and  Close  operates  as  expected.  Operations  Name.Object  and  Lookup. 
Object  manipulating  persistent  object  names  in  the  corresponding  database. 
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Faculty_Set  is  new  Set (Faculty. Obj ect) ; 
Jones_Advisors  :  Faculty_Set. Object  := 

Faculty_Set .Select_Subcollection( 

"exists  S  in  Advisees:  S.Last_Nanie  =  ’Jones’"); 


Figure  9:  Example  Collection  Query 


Student_Set  is  new  Set (Student .Object) ; 

A_Student_Set  :  Student_Set .Object  := 

Database . Query (My_Dat abase , 

"select  S  "  & 

"from  S  in  Students,  F  in  Faculty  "  & 

"where  Abs(S.SSAN  -  F.SSAN)  <=  5  and  "  & 

"S  in  Relationship_One_To_Many_Traverse(F,  ’Advisees’)"); 


Figure  10:  Example  Database  Query 


5  Ada  OQL 

Consistent  with  the  other  ODMG-93  OQL  language  bindings,  the  loosely  coupled  approach  is 
recommended  in  the  initial  Ada  binding,  with  predicates  introduced  as  strings  that  are  parsed, 
optimized,  and  evaluated  at  runtime  rather  than  at  compile  time.  An  ODBMS  implementation  of 
Ada  OQL  will  therefore  require  a  runtime  parser  to  translate  the  predicate  from  Ada  syntax  to  the 
syntax  required  by  the  underlying  system. 

5.1  Collection  Queries 

Collections  can  be  filtered  using  the  two  operations  defined  for  each  collection  generic  package: 
Select-Subcollection  and  Select-Element.  Each  takes  the  predicate  string  as  its  sole  parameter. 
For  example,  assuming  extent  Faculties  contains  all  instances  of  object  class  Faculty,  the  query 
in  Figure  9  returns  all  Faculty  instances  advising  a  student  with  a  last  name  of  “Jones.” 

5.2  Database  Queries 

More  complex  query  operations  defined  over  an  entire  database  should  also  be  defined.  Figure 
10  illustrates  an  example  query  selecting  all  students  whose  SSANs  are  within  5  points  of  their 
advisors. 
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subtype  Object  is  System. Address; 

procedure  Name_Object(An_Object  :  in  out  Object; 

Name  :  in  String) ; 


Figure  11:  Example  Address-based  Operation 


6  Producing  and  Implementing  an  Ada  83  Binding 

We  tested  our  Ada  binding  by  writing  vendor  specific  package  bodies  for  the  ObjectStore  and 
ITASCA  ODBMS  products.  We  used  Sun  Ada  83  on  a  Sun  Sparcstation  2  as  the  compiler.  The 
issues  we  dealt  with  were  Ada  83’s  inability  to  model  inheritance  and  the  current  lack  of  an  ODMG- 
93  standard  interface  for  the  two  ODBMS  products.  Below  we  briefly  discuss  the  Ada  83  issues 
and  our  implementation  efforts. 

6.1  A  New  Approach:  Address-based 

Ada  83  requires  a  different  approach  for  defining  the  language  binding:  address-based.  This  ap¬ 
proach  uses  pointers  by  defining  the  high-level  database  types  such  as  Object  and  Collection. Set 
as  a  subtype  of  the  platform-dependent  System.  Address.  Figure  11  shows  the  redefinition  of  the 
ODMG-93  construct  of  Figure  4  using  the  address-based  approach. 

This  technique  allows  the  definition  of  address  parameters  to  and  from  the  various  ODMG-93 
constructs  without  regard  to  the  data  they  reference.  If,  however,  an  address  referencing  an  invalid 
or  inappropriate  data  structure  is  passed  to  an  ODMG  operation,  an  exception  is  raised.  This 
method  removes  the  need  to  overload  operations  based  on  all  the  valid  data  types  the  user  may 
specify;  however,  it  does  require  the  majority  of  object  related  error-checking  to  be  performed  at 
runtime  rather  than  at  compile  time. 

6.2  Additional  Considerations 

Attribute  and  method  definition  in  Ada  83  packages  required  a  more  sophisticated  ODL  preproces¬ 
sor  than  that  for  Ada  9X.  A  convention  had  to  first  be  decided  upon  to  communicate  inheritance 
between  packages  to  the  preprocessor,  which  could  then  use  its  native  constructs  to  make  a  corre¬ 
sponding  representation. 

Implementing  an  Ada  83  binding  for  an  ODBMS  is  further  complicated  by  the  nonexistence 
of  any  commercial  ODBMS  implemented  in  Ada  83.  As  a  result,  an  implementation  must  use  a 
programming  language  to  which  Ada  can  link  using  its  pragma  commands.  E  this  language  does 
not  have  a  mechanism  for  specifying  inheritence,  a  simulation  technique  must  be  devised. 

6.3  Prototype  Implementation 

The  address-based  approach  mentioned  in  Section  6.1  was  implemented  using  the  C  programming 
language  interface  libraries  for  the  ITASCA  and  ObjectStore  ODBMS  products  [4].  Defining  the 
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high-level  types  as  subtypes  of  System.  Address  facilitated  implementing  the  binding;  however, 
for  the  reasons  stated  in  Section  6.2,  the  ObjectStore  ODL  preprocessor  required  a  much  greater 
degree  of  involvement  than  the  ODL  preprocessor  for  ITASCA. 

The  primary  reason  for  this  occurrence  is  the  strong  typing  of  ObjectStore’s  implementation 
language.  The  C  language  implementation  accessing  ObjectStore’s  functionality  necessitated  the 
creation  of  parallel  data  types  before  attribute  values  could  be  manipulated.  This  required  the  class 
of  the  object  to  be  determined  so  that  its  address  could  be  appropriately  converted,  all  of  which 
must  be  decided  at  compile  time.  ITASCA,  on  the  other  hand,  has  no  requirement  for  declaring 
parallel  data  types.  Although  its  functionality  was  accessed  using  the  C  interface,  its  ODBMS 
implementation  language  is  Lisp,  a  weakly  typed  language.  As  a  result,  no  parallel  data  types 
were  required  and  attribute  values  could  be  manipulated  using  the  object-oriented  message  passing 
techniques  for  Lisp  and  CLOS. 

Additionally,  the  ODBMS  was  required  to  model  inheritance  for  Ada  83.  ITASCA’s  ability  to 
functionally  specify  inheritance  between  classes  allowed  inherited  attributes  to  be  manipulated  in 
exactly  the  same  way  as  non-inherited  attributes.  Because  C  cannot  model  inheritance,  a  technique 
for  its  simulation  was  required.  This  further  required  the  ODL  preprocessor  to  resolve  the  simulation 
technique  when  inherited  attributes  were  accessed. 

6.4  Summary  of  Results 

Operating  under  the  assumed  existence  of  ODL  preprocessors  for  each  ODBMS,  we  were  able  to 
produce  a  portable  Ada  database  application.  With  the  simple  process  of  exchanging  the  vendor- 
specific  package  bodies,  the  Ada  binding  and  the  application  could  be  recompiled  and  executed  using 
both  ObjectStore  and  ITASCA.  The  ObjectStore  version  could  take  advantage  of  the  sophisticated 
performance-based  memory-mapping  and  clustering  techniques  inherent  in  this  ODBMS^ ,  although 
its  implementation  was  more  preprocessor-dependent  than  its  counterpart.  The  ITASCA  version 
exploited  the  language  neutrality  of  its  underlying  system  to  produce  an  elegant  and  straightforward 
implementation. 

The  ability  to  produce  portable  Ada/ODBMS  applications  that  can  take  advantage  of  the  unique 
strengths  of  any  system  represents  the  fundamental  motivation  behind  ODMG-93.  Its  evolution  as 
well  as  the  evolution  of  the  resulting  language  bindings  will  give  ODBMS  programmers  a  powerful 
facility  in  the  near  future. 
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A  Proposed  Ada  Binding 

This  appendix  contains  our  complete  Ada  binding  for  the  proposed  ODMG-93  standard,  organized 
by  Ada  package. 

A.l  Persistent 

with  Database; 
package  Persistent  is 

type  Object  is  private; 

type  Reference  is  access  all  Object’Class; 

function  Create (A_Database  :  in  Database .Object ; 

Clustering  :  in  Reference  :=  null) 

return  Object; 

procedure  Delete(An_Object  :  Object); 
procedure  Mark_Modif ied(An_Object  :  in  Object); 

private 

String_Max  :  constant  :=  300; 
type  Object  is 
record 

Name  :  StringCl  ..  String_Max) ; 

Modified  :  Boolean; 

end  record; 
end  Persistent; 

A. 2  Database 

with  System,  Persistent,  Collection; 
package  Database  is 

subtype  Object  is  System. Address; 

function  Open_Database(Name  :  in  String) 
return  Object; 

procedure  Close_Database(A_Database  :  in  Object); 

procedure  Name_0bject(An_0bject  :  in  out  Persistent. Object; 

Name  :  in  String; 

A_Database  :  in  Object); 

function  Lookup_0bject (Name  :  in  String; 

A_Database  :  in  Object) 
return  Persistent .Object ; 
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package  Persistent_Collection  is  new 
Collection (Persistent. Object) ; 
function  Query (A_Database  :  in  Object; 

Predicate  :  in  String) 
return  Persistent .Collect ion . Object ; 
function  Query (A.Database  :  in  Object; 

Predicate  :  in  String) 
return  Persistent .Object ; 
end  Database; 

A.  3  Transaction 

with  System; 
package  Transaction  is 

subtype  Object  is  System. Address ; 

function  Start  return  Object; 

procedure  Commit_Txn(A_Transaction  :  in  Object); 
procedure  Abort_Txn(A_Transaction  :  in  Object); 
procedure  Checkpoint (A.Transaction  :  in  Object); 
procedure  Abort_To_Top_Level; 
end  Transaction; 

A. 4  Relationships 

with  Persistent,  Set; 
package  Relationships  is 

package  Persistent.Set  is  new  Set (Persistent .Object) ; 
procedure  Initialize; 

procedure  Relate_0ne_To_0ne .Create 
(Relationship  :  in  String; 

An.Object  :  in  out  Persistent. Object; 

Related.Object  :  in  out  Persistent .Object) ; 

procedure  Relate. One.To.One.Delete 
(Relationship  :  in  String; 

An.Object  :  in  out  Persistent .Object) ; 

function  Relate. One.To.One.Traverse 
(Relationship  :  in  String; 

An.Object  :  in  Persistent .Object)  return  Persistent .Object 

procedure  Relate.One.To.Many.Create 
(Relationship  :  in  String; 

An.Object  :  in  out  Persistent .Object ; 

Related.Set  :  in  Persistent.Set .Object) ; 
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procedure  Relate_One_To_Many_Delete 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object) ; 

procedure  Relate_0ne_To_Many_Add_0ne_To_0ne 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object ; 

Object_To_Add  :  in  out  Persistent .Object) ; 

procedure  Relate_0ne_To_Many_Remove_0ne_To_0ne 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent. Object; 

Object_To_Remove  :  in  out  Persistent .Object) ; 

function  Relate_One_To_Many_Traverse 
(Relationship  :  in  String; 

An_0bject  :  in  Persistent .Object)  return  Persistent_Set .Object; 

procedure  Relate_Many_To_Many_Delete 
(Relationship  :  in  String; 

An_Object  :  in  out  Persistent. Obj ect) ; 

procedure  Relate_Many_To_Many_Add_One_To_One 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object ; 

Object_To_Add  :  in  out  Persistent .Object) ; 

procedure  Relate_Many_To_Many_Remove_One_To_One 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent. Obj ect; 

Object_To_Remove  :  in  out  Persistent .Object) ; 
procedure  Relate_Many_To_Many_Add_One_To_Many 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent. Obj ect; 

Set_To_Add  :  in  Persistent _Set .Object) ; 

procedure  Relate_Many_To_Many_Remove_One_To_Many 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object ; 

Set_To_Reniove  :  in  Persistent_Set .Object) ; 

procedure  Relate_Many_To_Many_Remove_All_From 
(Relationship  :  in  String; 

An_0bject  :  in  out  Persistent .Object) ; 

end  Relationships; 

A.  5  Iterator 

with  System; 
generic 

type  Collected_Object  is  private; 
package  Iterator  is 
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subtype  Object  is  System. Address; 


function  More(An_Iterator  :  in  Object)  return  Boolean; 
procedure  First (An_Iterator  :  in  out  Object; 

An_0bject  :  out  Collected_Object) ; 

procedure  Last (An_Iterator  :  in  out  Object; 

An_0bject  :  out  Collected_Object) ; 

procedure  Next (An_Iterator  :  in  out  Object; 

An_0bject  :  out  Collected_Object) ; 

procedure  Reset (An_Iterator  :  in  out  Object); 
procedure  Delete (An_Iterator  :  in  out  Object); 
end  Iterator; 


A.  6  Collection 

with  System,  Iterator; 
generic 

type  Collected_Object  is  private; 
package  Collection  is 

Cardinality  :  Integer; 

Empty  :  Boolean; 

Ordered  ;  Boolean; 

Allows_Duplicates  :  Boolean; 


subtype  Object  is  System. Address ; 

subtype  Iterator_Object  is  System. Address; 


function  Create  return  Object; 
procedure  Delete (A_Collection  :  in  out  Object); 
function  Copy (A_Collection  :  in  Object)  return  Object; 
procedure  Insert_Element (An_0bject  :  in  Collected_Object 

A_Collection  :  in  out  Object); 

procedure  Remove.Element (An.Object  :  in  Collected_Object 

A_Collection  :  in  out  Object); 

function  Select_Element (A_Collection  :  in  Object; 

Predicate  :  in  String) 
return  Collected_Object ; 

function  Select_Subcollection(A_Collection  :  in  Object; 

Predicate  :  in  String) 

return  Object; 


function 

return 


Contains_Element (A_Collection 
An_0bject 


Boolean; 


in  Object; 

in  Collected_Object) 
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function  Create_Iterator (A_Collection  :  in  Object) 
return  Iterator_Object ; 
end  Collection; 


A.7  Set 

with  System,  Collection; 
generic 

type  Collected_Object  is  private; 
package  Set  is 

package  Set_Collection  is  new  Collection(Collected_Object) ; 
type  Object  is  new  Set_Collection. Object; 

function  Create  return  Object; 

procedure  Insert _Element (An_Object  :  in  Collected_Object ; 

A_Set:  :  in  out  Object); 

function  Union(Set_One  :  in  Object; 

Set_Two  :  in  Object)  return  Object; 
function  Intersection(Set_One  :  in  Object; 

Set_Two  :  in  Object)  return  Object; 

function  Difference (Set_0ne  :  in  Object; 

Set_Two  :  in  Object)  return  Object; 
function  Is_Subset(Set_One  :  in  Object; 

Set_Two  :  in  Object)  return  Boolean; 

function  Is_Proper_Subset (Set_0ne  :  in  Object; 

Set_Two  :  in  Object)  return  Boolean; 


function  Is_Superset (Set_0ne  :  in  Object; 

Set_Two  :  in  Object)  return  Boolean; 


function  Is_Proper_Superset (Set_0ne 

Set_Two 


end  Set; 


in  Object; 

in  Object)  return  Boolean; 


A. 8  Bag 

with  System,  Collection; 
generic 

type  Collected_Object  is  private; 
package  Bag  is 

package  Bag_Collection  is  new  Collection(Collected_Object) ; 
type  Object  is  new  Bag_Collection. Object; 

function  Create  return  Object; 

procedure  Insert .Element (An_0bject  :  in  Collected.Object ; 

A_Bag  :  in  out  Object); 
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procedure  Remove_Elemeiit (An_0bject  :  in  Collected_Object ; 

A_Bag  :  in  out  Object); 
function  Select_Subcollection(A_Bag  :  in  Object; 

Predicate  :  in  String) 

return  Object; 

function  Union(Bag_One  :  in  Object; 

Bag_Two  :  in  Object)  return  Object; 
function  Intersection(Bag_One  :  in  Object; 

Bag_Two  :  in  Object)  return  Object; 
function  Difference (Bag_0ne  :  in  Object; 

Bag_Two  :  in  Object)  return  Object; 

end  Bag; 


A.  9  List 

with  System,  Collection; 
generic 

type  Collected_Object  is  private; 
package  List  is 

Current _Position  :  Integer; 

package  List_Collection  is  new  Collection(Collected_Object) ; 
type  Object  is  new  List_Collection. Object; 


function 

procedure 

function 

return 

procedure 


procedure 


procedure 

procedure 

procedure 

procedure 

procedure 

procedure 


Create  return  Object; 

Insert_Element(An_Object  :  in  Collected_Object ; 

A_List  :  in  out  Object); 
Select_Subcollection(A_List  :  in  Object; 

Predicate  :  in  String) 

Object ; 

Insert_Element_After (An_0bject  :  in  Collected_Object ; 

Position  :  in  Integer; 

A_List  :  in  out  Object); 

Insert_Element_Bef ore(An_Object  :  in  CoIlected_Object 

Position  :  in  Integer; 

A_List  :  in  out  Object); 

Insert _First_Element (An_0bject  :  in  Collected_Object ; 

A_List  :  in  out  Object); 

Insert_Last_EIement(An_Object  :  in  Collected_Object ; 

A_List  :  in  out  Object); 
Remove_Element_At (Position  :  in  Integer; 

A_List  :  in  out  Object); 
Remove_First_Element (A_List  :  in  out  Object); 
Remove_Last_Element (A_List  :  in  out  Object); 
Replace_Element_At (An_Object  :  in  Collected_Object ; 

Position  :  in  Integer; 
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A_List  :  in  out  Object); 

function  Retrieve_Element_At (Position  :  in  Integer; 

A_List  :  in  Object) 

return  Collected_Object ; 

function  Retrieve_First_Element (A_List  :  in  Object) 
return  Collected_Object ; 

function  Retrieve_Last_Element (A_List  :  in  Object) 

return  Collected_Object ; 
end  List; 

A. 10  Array-Type 

with  System,  Collection; 
generic 

type  Collected-Object  is  private; 
package  Array_Type  is 

package  Array-Collection  is  new  Collection(Collected_Object) ; 
type  Object  is  new  Array-Collection. Object; 

procedure  Insert_Element-At(An-Object  :  in  Collected-Object; 

Position  :  in  Integer; 

An_ Array  :  in  out  Object); 

procedure  Remove-Element -At (Position  :  in  Integer; 

An-Array  :  in  out  Object); 

procedure  Replace-Element-At (Au-Object  :  in  Collected-Object; 

Position  :  in  Integer; 

An-Array  :  in  out  Object); 

function  Retrieve-Element-At (Position  :  in  Integer; 

An-Array  :  in  Object) 

return  Collected-Object; 

procedure  Resize (New-Size  :  in  Integer; 

An-Array  :  in  out  Object); 

end  Array-Type; 
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